最後一天。按慣例，收官篇要嘛煽情要嘛喊口號，但這個系列從第一天就說好了：它是一本除錯日記。所以收官也用工程師的方式——交成績單。

半年的自架、30 天的書寫，這套系統現在到底是什麼狀態？花了多少錢？哪些決定值回票價、哪些錯誤付了學費？以及，它接下來要去哪。

成績單：數據總結

這張表裡唯一沒有數字的那一格，是我最滿意的一格。

Day 7 解釋過我為什麼不報月費：這套系統橫跨定額訂閱與按量計費，前者無法歸屬、後者小到失去代表性，任何數字都會誤導你。所以我改用「費用意外次數」當指標，而它現在是 0。

這個換法一開始是不得已，後來我發現它其實更誠實。月費會隨著單價、用量、我這個月忙不忙而漂移；「有沒有再被帳單嚇到」則直接對應我真正在乎的東西。治理買到的從來不是便宜，是沒有驚喜。

再貼一次它平凡的一天：五點抓美股收盤、清晨同步持倉損益、七點半生活簡報、八點投資晨報、上午整合記憶（對，就是 Day 9 那個跑在錯誤時區的傢伙——它到今天還在上午跑，搬回凌晨的工單還排在隊伍裡）、每十五分鐘巡一輪家居狀態、下午抓台股收盤、二十二點發當日收尾——全年無休，而我多數時候感覺不到它的存在。好的自動化就是這樣：安靜到你會忘記，可靠到你敢忘記。

不過那張表裡的「41 個零 LLM、Claude 旗艦 0 個」值得再說一次，因為它推翻了我自己一開始的想像。我原本以為終點是一個聰明的 Agent 替我打理一切；半年後的實況是一堆笨腳本準時做完該做的事，而 AI 真正發揮價值的地方，是我坐下來跟它一起改這些腳本的時候。這不是我規劃的結果，是被現實磨出來的形狀——而我認為它比原本的想像好。

最有價值的四個決定

**① 全 Markdown 的狀態層（Day 13）。**人格、記憶、規則、持倉、報告，全部是純文字檔。這個看似土法煉鋼的決定，是後來每件好事的地基：LLM 讀寫零成本、git 能版控、同步工具能搬運、我隨時能打開看它「在想什麼」。如果狀態鎖在資料庫裡，雙 AI 協作、記憶治理、這個系列的大半內容都不會存在。

② 把教訓寫成閘道，而不是記在腦裡（Day 24）。$40 事故之後，真正改變系統體質的不是那次修復，是把修復經驗變成五道可機器判定的閘門、再配一個每天執法的掃描 job。從此犯過的錯在結構上不可能再犯。個人系統最大的敵人是自己的隨性，制度是對抗隨性唯一有效的武器。

**③ 分層——所有意義上的分層。**記憶分三層（Day 8）、監控分兩層（Day 20）、模型分三層（Day 23）、授權按破壞半徑分級（Day 27）。回頭看，這套系統裡每個運作良好的部分都有同一個形狀：**把不同性質的東西拆開，讓每一層用自己的頻率和規則運作。**架構師講了幾十年的老話，在一台家用 NAS 上再次驗證。

**④ 承認大腦不在這台機器上（Day 1、7、15）。**這是四個決定裡我最晚才想通、也最徹底的一個——它甚至推翻了我當初做這件事的初衷。

我一開始的目標是「養一個聰明的 Agent」。半年後的實況是：思考在訂閱那一側跟我一起發生，NAS 上這台只負責記得與準時。Clawrion 從我想像中的大腦，變成一個持久化與執行系統。

推我走到這一步的不是什麼架構哲學，是計價模式：**跟 AI 一起思考的邊際成本趨近於零，讓機器自己思考卻要按次跳表。**一旦這個價差成立，把思考搬到有人在場的那一側就是唯一理性的做法——而且順帶解決了品質問題，因為半夜沒有人會發現它想錯了。

如果只能留一句給明年的自己：別問「這件事能不能自動化」，先問「這件事需不需要有人在場」。

付了學費的四個錯誤

**① 相信預設值（Day 22）。**沒有顯式指定的模型、順手設的 fallback、沒設上限的重試——每個「出廠設定」都是我沒審過的風險。學費一夜 $40，以教訓的密度來說很便宜。

**② 相信外部資料（$864 假股價，Day 18）。**HTTP 200 不代表資料是對的。一筆五倍於實價的假股價穿過整條 pipeline，差點進了投資決策。防呆層本該是第一天就有的東西，我卻等到中毒才補。

**③ 相信「自己家的系統」不需要安全審查（Day 26）。**token 進 git、PAT 嵌 URL、密碼寫筆記——三個漏洞全是自己埋的，而 workspace 早就是「多機同步 + 對外服務 + LLM 天天讀」的分散式攻擊面。心態比技術落後，是最貴的落後。

**④ 相信自己的監控。**這個錯誤跟前三個不同——前三個是「我沒做」，這個是「我做了，而且做錯得很有信心」。它值得獨立一節，就在下面。

前三個錯誤的共同句式是「相信」。工程的成熟度，大概就是把「相信」逐項換成「驗證」的過程——而第四個會告訴你，這個過程比想像中還要再深一層。

第四個錯誤：相信自己的監控

寫到這裡我發現，前面那三個錯誤還有個共同的溫柔之處——它們最後都被我發現了，而且發現的方式都是系統主動告訴我：帳單跳出來、報告數字不對、掃描列出漏洞。

系列收尾前的那一週，我撞到不會被告訴的那一種。

心跳停擺兩天而排程狀態全綠（Day 20）、一個從上線起就不可能失敗的合規檢查（Day 20）、六個寫了但從未執行的測試（Day 28）、量了半年卻一直是空值的費用曲線（Day 25）——四件事，四個不同的機制，同一個形狀：

前三個錯誤是「我相信了不該相信的外物」；這一個是「我相信了自己的眼睛」。

監控有個特別的失效模式：它壞掉的時候通常不報錯，只會安靜地回報一切正常。沉默和健康，在儀表板上長得一模一樣。

所以最後一週我加了一道手續，現在它是我裝任何監控的收尾動作：寫完偵測邏輯，先造一個假故障餵給它，看它會不會叫。看得到，這個監控才算完成；只是跑得動，不算。

第一次做這件事就抓到了那個合規掃描。它連續好幾個月回報零違規——而我從來沒問過它一句：「如果真的有違規，你抓得到嗎？」

四個錯誤現在有了完整的句式：前三個是把「相信」換成「驗證」，第四個是連驗證本身也要被驗證。

Roadmap：它接下來要去哪

系統不會停在 Day 30。但接下來的方向，跟前三十天不太一樣——不再是「加功能」，而是一個更大的題目。先講想玩的：

1. **拿新玩具讓它進化。**Agent 圈最近很熱鬧——自主迴圈（loop）類的自我改進機制、新一代的記憶框架，這些我都想拿來試。但試的標準只有一條：能不能解決我真實的痛點——例如讓記憶從「存得好、查得到」進化成「它自己想起來」（在對的時機把三個月前的脈絡主動端出來）、讓它修自己修得更聰明——而不是因為紅就裝。
2. **本地模型實驗。**現在的隱私邊界靠「選擇哪些資料給雲端 API」維持；下一步想試小型本地模型跑低敏感任務，把資料駐留的選項真正握在手裡——也呼應 Day 29 那個資料出不了門的企業命題。

但把這些排開之後我發現，真正的下一章不是任何一個新功能，而是一件聽起來平凡、做起來最難的事：長期運營。

用 AI 單次解決一個問題，在 2026 年已經是小事；真正難的是接下來的每一個月、每一年——讓它持續維持高水準的表現，跟著我的生活一起變。我的持倉會換、作息會改、在乎的事會移動，而它的記憶、規則、排程要一直跟得上：不腐化、不漂移、不安靜地退化成背景噪音。這三十篇寫的是「從零到一個管家」；下一個三十篇如果存在，主題會是「跟一個管家過日子」——而我現在就可以告訴你，後者難得多。

這個判斷有一個現成的對照組：最近圈子裡有一波「棄坑潮」——不少當初跟我前後腳架起同款框架的人，玩幾個月就收了。我不覺得是框架不好，而是那條曲線本來就長這樣：剛開始誰都不知道 prompt engineering 是什麼、agent 能做到什麼程度，新鮮感撐起第一個月；然後 API 帳單、維護成本、「它到底幫了我什麼」的質疑接踵而來。撐過去的方式不是熱情，是跟著自己的生活持續改它——場景是用出來的，不是裝好那天就有的；角色與權責是一次次調整劃分出來的，劃清楚了，你才真的理解這個「管家」是什麼、該擺在生活的哪個位置。**棄坑的多半不是輸給技術，是還沒用到長出自己的模式就停了。**用 AI，是時間的函數——這也是為什麼下一章是長期運營，而不是更多功能。

誠實面對擴展邊界：這套架構能長到多大？

Roadmap 講完想去哪，也該講清楚它走不到哪——可維護性這半年及格了，可擴展性則有三道看得見的天花板。

**第一道：狀態層的檢索天花板。**全 Markdown 是四個決定裡最有價值的一個，但它的記憶檢索本質是全文掃描——幾十個檔案時又快又透明，幾千個檔案時就是災難。目前靠分層歸檔（Day 10）延後撞牆，但如果 Agent 數量或記憶量再長一個量級，勢必要在 Markdown 之上加一層索引（向量或倒排），而那一刻「隨時打開看它在想什麼」的透明性就要開始付出代價。這是透明性與規模的直接交換，躲不掉。

**第二道：成本與 session 隨 agent 數線性成長。**每加一個 Agent 角色，就多一份 session 檔案要管、多一組排程要治理、多一份 token 流量。目前六個角色靠 janitor 每日修剪與週期壓縮（Day 10）撐住，但這些機制的複雜度本身也在長——管理成本不會因為自動化而消失，只是換了形狀。個人系統合理的規模上限，我猜在 10 個角色以內。

第三道：單台 NAS 的物理天花板。一台 DS723+ 扛七個容器已近舒適區邊緣，而它同時是唯一的故障點——Day 20 那些自癒機制修的都是軟體，硬碟壞掉、主機板燒掉沒有任何腳本救得了。機構會用叢集和異地備援解這題；家用系統的務實解是接受它，然後把「重建成本」壓低——全 Markdown 加 git 加設定檔案化的另一個好處，就是整套系統的「靈魂」可以在一個週末內於新硬體上復活。

一句話總結：**這套架構是為「一個人、一個家、十個角色以內」設計的，而且我認為在這個範圍裡它是對的。**超出這個範圍需要的不是優化，是換架構——知道邊界在哪，跟知道怎麼蓋一樣重要。

一個需求的一生——這套系統是怎麼被造出來的

收官前還欠一個角度。前面二十九篇講的都是「系統做了什麼」；最後想講它是怎麼被造出來的——用一個真實例子，把「一個需求從我嘴裡到生產上跑」完整走一遍。

某天早上我打開自己的市場頁，頁面頂端掛著橘色警告：「⚠ 行情快取可能過時」。可當下是早上十一點半，快取停在凌晨四點——那是美股收盤價，本來就是最新的價。點進去看判斷邏輯，一行就懂：「超過 2 小時算過時」；而刷新排程的最長間隔是 17 小時（收盤到開盤，沒有新價可抓）。門檻比它要守護的訊號的正常範圍還緊，於是它天天在白天喊狼來了。這正是我在 Day 18 當金句寫過的教訓——我寫過那句話，還是踩了。把現象講給 AI，它診斷出根因、給了正解（過時門檻要大於最長刷新間隔 → 18 小時）、抽出獨立函式、補上測試——測試還特地把門檻改回兩小時、確認會變紅（Day 28 的規矩）。從看到 bug 到修好上線，一杯咖啡的時間，我沒寫一行程式碼。

而這個迴圈，就是半年來每一支腳本、每一個頁面誕生的方式：

方向盤那幾格始終是我：要不要做、邊界在哪、上不上線、以及在真實使用裡認出「這不對」；其餘每一格，AI 都能代勞。

迴圈上手之後，它的範圍就不限於系統了——當「許願」變成一種習慣，整個生活都是需求的來源。女兒需要練英文，我就許願一個小遊戲：「做一個練英文單字的小遊戲，介面講中文、要有計分、答對要有音效」——當天晚飯前，她已經玩著一個為她量身做的網頁遊戲，而我，還是一行程式碼都沒寫。從市場頁的過時警告到女兒的單字遊戲，同一個迴圈、同一種分工。這可能才是這個時代最被低估的能力：不是寫程式，是看見需求、把願望講清楚、然後認得出「這不對」。

所以，這套系統我一行程式碼都沒寫，但它是我的——每個頁面、每條規則，都始於我的一句話、經過我的一次驗收。**AI 負責能不能跑，工程判斷歸我。**而它最誠實的一次驗收，永遠是我自己每天打開儀表板、皺起眉頭的那一刻。

完賽感言

30 天寫下來，最深的體會是：**寫作是最嚴格的 code review。**很多我以為想清楚的設計，寫到一半發現講不圓；講不圓的地方，十有八九就是設計還沒收斂的地方。這個系列修好的 bug，不比它記錄的少。

如果你只帶走一句話，我希望是這句：自架 AI Agent 系統，難的從來不是「讓它動起來」——教學文照抄一個週末就夠——難的是讓它在你不看著的時候，把事情做對、把錢花對、把秘密守住。那才是從玩具到管家的距離，也是這 30 篇真正想講的事。

謝謝你看到這裡。我要去看今天的晨報了——八點整，它準時躺在那裡，一如既往。

🔑 這篇的關鍵字
四個決定：全 Markdown 狀態層 · 教訓寫成閘道 · 所有意義上的分層 · 承認大腦不在這台機器上
四個錯誤：相信預設值 · 相信外部資料 · 相信自家系統不用安審 · 相信自己的監控（一個從來不報錯的檢查，跟不存在的檢查長得一模一樣）
一個需求的一生：使用長出需求 → 我定義與驗收 → AI 實作部署 → 真實使用揭穿 → 迭代 · 許願是一種能力 · 我沒寫過一行程式碼，但它是我的
用 AI 是時間的函數（棄坑多半是還沒長出自己的模式就停了）· 留給明年的一句：先問「這件事需不需要有人在場」

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。